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ABSTRACT 



A preloader works in conjunction with a web/app server and 
optionally a profile server to cache web page content ele- 
ments or components for faster on-demand and anticipatory 
dynamic web page delivery. The preloader uses a cache 
manager to manage requests for retrievals, insertions, and 
removal of web page components in a component cache. 
The preloader uses a cache replacement manager to manage 
the replacemeal of components in the cache. While the 
cache replacement manager may utilize any cache replace- 
ment policy, a particularly effective replacement policy 
utilizes predictive information to make replacement deci- 
sions. Such a policy uses a profile server, which predicts a 
user's next content request. The components that can be 
cached are identified by tagging them within the dynamic 
scripts that generate them. The preloader caches components 
that are likely to be accessed next, thus improving a web 
site's scalability. 

10 Claims, 13 Drawing Sheets 
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DYNAMIC PAGE GENERATION 
ACCELERATION USING COMPONENT- 
LEVEL CACfflNG 

RELATED APPUCAnONS 

The present application claims priority to a provisional 
application filed in the U.S. Patent and Trademark Office on 
Apr. 10, 2000 with Ser. No. 60A95,806. The contents of the 
provisional application are hereby incorporated by refer- 
ence. 

HELD OF THE INVENTION 

The present invention generally relates to delivering web 
pages over the Internet. More particularly, the present inven- 
tion relates to caching web page components to enable 
improved web page delivery speeds and web site scalability. 

BACKGROUND OF THE INVENTION 

A critical issue in conducting commerce via the Internet 
("e-commerce") is scalability. E-commerce has experienced 
phenomenal growth dxiring the past few years, and is 
expected to continue this upward trend for years to come. 
Some predictions claim that e-commerce revenues will 
exceed $1.3 trillion by 2003. Along with this growth in 
revenue comes significant increases in web traffic. 
E-commerce web sites are having trouble supporting such 
extreme growth while maintaining acceptable qualities of 
service with the current state of Internet infrastructure 
technology. 

As the number of Internet customers increases, 
e-commerce companies are required to deliver web pages to 
tens of thousands of customers simultaneously. This require- 
ment can place a great strain on the computing resources of 
e-commerce companies. Moreover, most e-commerce com- 
panies are delivering dynamic web pages to customers, 
rather than static web pages. Dynamic web pages enable the 
delivery of tailored information to a customer, because the 
dynamic web page is created on-the-fly, in response to a set 
of parameters associated with a particular customer, such as 
information related to the customer's buying habits or 
Internet browsing behavior. 

Many web sites currently utiUzc application servers to 
dynamically generate Hypertext Markup Language (HTML) 
pages. Application servers execute scripts in order to gen- 
erate (or create) these dynamic web pages. These scripts 
typically do a significant amount of work to generate a 
dynamic web page. For example, the application server may 
retrieve web page content from database systems (located 
locally or remotely), content transformations may be 
required (e.g., from XML to HTML) (XML is an acronym 
for Extensible Markup Language), and other business logic 
may be executed (e.g., personalization logic). In the absence 
of web page caching, each request for a dynamic web page 
requires that the entire script be executed each time. When 
the same web page content is requested and generated 
repeatedly, this results in unnecessary load on the apphca- 
tion server, and hence longer (and often unacceptable) 
response times for site visitors. 

In order to reduce the overhead associated with dynamic 
page generation, pages (or portions of pages) may be cached 
in main memory. Caching requires that policies be estab- 
lished to govern the replacement of pages in the cache. 
Commonly used cache management policies are Least 
RecenUy Used (LRU) and Most Recently Used (MRU) 
cache policies, both of which have been used extensively in 
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the operating systems context. However, these schemes are 
based purely on access history, and are often inappropriate 
in the context of the web. 

Today, many sites delivering dynamic web pages experi- 

5 ence serious performance problems in terms of response 
limes (i.e., the time to deliver a complete web page to a 
cTistomer). For example, a recent study reports that the 
average page download time for the most popular auction 
sites is 6.30 seconds. Poor performance can be extremely 

50 detrimental to a web site's ability to, successfully conduct 
commerce online. 

Another study predicts that if a web page requires longer 
than eight seconds to deliver to a customer, then 30% of 
customers will abandon the web page request. Unacceptable 
web page delivery delays are a known cause for customer 
abandonment (i.e., customer attrition). It has been estimated 
that a one second improvement in page loading time (i.e., 
from 6.30 seconds to 5.30 seconds) can reduce the aban- 
donment rate from 30 percent to about 7 percent. Another 
study indicates that customer attrition attributable to aban- 
donment may cost the online business community upwards 
of $100 million per month. 

To solve the attrition problem, many e-commerce provid- 

^ crs are increasingly adopting dynamic page generation tech- 
nologies to dynamically display content due to the signifi- 
cant flexibihty it awards the designer in deUvering custom 
content to users. However, dynamic page generation, while 
flexible, comes with a cost. As explained previously, web 
and apphcation server ("web/app server**) scalabDity is 
significantly reduced because pages are now generated "on 
demand", which places additional load on the web/app 
servers in order to retrieve and format the requested content. 
Consequently, even under moderate traffic loads, page gen- 
eration times slow down significantly. 

One use of dynamic web page generation involves the 
promotion of related products. For example, a visitor at an 
online book web site may travel down the web page link 
path: Fiction-Thriller-Lcgal Thriller. If it is known (e.g., 
through accumulating empirical Internet browsing behavior 
data) that customers who travel down this linkpath arc 
statistically likely to also be interested in fusion jazz — this 
type of knowledge is actually widely accumulated these 
days — then the next web page presented to the customer 

45 might have a component including a reference to fusion jazz. 
One solution, the eOlue Server, manufactured and mar- 
keted by Chutney Technologies, Inc. of Atlanta, Ga., is 
designed to quickly establish relationships between a cus- 
tomer's browsing behavior and previously accumulated 

50 empirical behavior data, so that such statistical knowledge 
can be utilized for various purposes, such as tailoring a web 
site to a customer's tastes or determining which items in a 
cache to replace. The eGlue Server (also called a profile 
server) is designed to provide such predictive knowledge to 

55 requesting applications. Given this context, the eGlue 
Server, immediately upon the detection of the Legal Thriller 
click by the visitor, would recommend that the page deliv- 
ered to the user contain an e -coupon from Tower Records 
with a discount in the fusion jazz category. Note that while 

60 the above example is in the context of delivering advertise- 
ments and promotions, the same functionality could be used 
in the context of caching Web content. In particular, the 
predictive knowledge could be used in the cache replace- 
ment policy for Web content that is cached. 

65 Given the extreme growth in Internet traffic as well as the 
increasing tise of dynamic page generation technologies, 
there is a need in the art to improve web and apphcation 
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server scalability. Scalability can be improved by caching response is sent, in response to the content element insertion 
components of dynamic web pages. Further improvements request. The insertion response indicates whether the con- 
in performance may be obtained by utilizing predictive tent element was successfiilly inserted into the component 
information in the cache replacement policy. cache. A determination is made as to whether the content 

5 element should reside in the component cache. The content 

SUMMARY OF THE INVENTION clement is removed from the component cache, in response 

The present invention solves the above-identified prob- ^ a determination that the content element should not reside 
lems by providing a preloader that works in conjunctioo component cache. The content element is associated 

with a web/app server and opUonally a profile server to "^^^ ^ ^^^"'^^^ '^^^^ ^ ^^"""^^ component 

cache web page content elements or components for faster ^^^^^'^^ response to a dctcrmmation that the content 

on-demand and anticipatory dynamic web page deUvery. ^^^"'^"^ ^^'^^^^ '^^'^^ ^ component cache. 
The preloader uses a cache manager to manage requests for ^ still another aspect of the invention, a component cache 

retrievals, insertions, and removal of web page components ^^^^ structure is provided for storing a current content 

in a component cache. The preloader uses a cache replace- element. A content element node is associated with the 

ment manager to manage the replacement of components in current content element The content element node com- 

the cache. The cache replacement manager may utilize any prises at least a NodelD data field, a NavProb data field, a 

cache replacement poUcy. However, a particularly effective NextNode data field, a Timestamp data field, and a Content 

replacement policy utilizes predictive information to make ^^^^ NodelD data field comprises a PagcID and a 

replacement decisions. Such a policy uses a profile server, Block ID and uniquely identifies the current content 

which proves a means of predicting a user's next content clement. The NavProb data field comprises a conditional 

request. The components that can be cached are identified by probability that the current content element will be needed 

tagging them within the dynamic scripts that generate them. *o generate a web page. The Timestamp data field comprises 

The Preloader caches components that are likely to be * that the current content element was last accessed, 
accessed next, thus improving a web site's scalability. Content data field contains a representation of the 

In one aspect of the present invention, a web page current content element. The NextNode data field comprises 

delivery system is provided for dynamically generating a ^ ^"^^^ contammg at least one destmaUon NodelD 

web page having at least one content clement. The web page ^epresentrng a destination content element that is reachable 

delivery system has a web/app server that receives a web ""^"^ '^^^^"^ element. 

page request from a user, generates a web page, and delivers 3^ various aspects of the present invention may be more 

the web page to the user . The web page delivery system also clearly understood and appreciated from a review of the 

has a preloader that receives content element retrieval following detailed description of the disclosed embodiments 
requests from the web/app server and dehvers content reference to the drawings and claims, 

elements to the web/app server, in response to receiving the 

content element retrieval requests. The web page deUvery 35 ^^^^^ DESCRIPTION OF THE DRAWINGS 
system also has a profile server that receives hint requests pic. 1 depicts the conventional steps required to satisfy a 

firom the preloader and dehvers hmts to the preloader. The vveb page request for delivery of a web page from a web 

preloader has a component cache and maintains the content server. 

elements in the component cache and delivers the content r-j^. ^ j • . . r n 

elements to the web server, in response to a deterrainaUoD ^ ,. "^'f " aph of the performance of a conven- 

that the bint indicates that the Jontent elements will be ^^'^ catalog-based web site that dynamically generates 
needed by the web/app server to generate the web page. °^ pages. 

In another aspect of the present invention, a method is ^ ^ * ""^^^ t^^f^ ^"^'^^^^ exemplary profile 

provided for delivering a web page. A web plge request is ^^^^'J^ d naSc wlb "''""P^''^ "^"^^^ 
received where the web page request corresponds to a web 45 ^ pages. 

page having at least one content element. It is determined ^^P^^^ ^ preloader that is an exemplary embodi- 

whether a tagged content element resides in a component °^ ^® present invenUon. 

cache, where the tagged content element corresponds to the FIG. 5 is a block diagram of an exemplary dynamic web 

requested content element. A content response is generated P^g^ and a script that is used for generating the dynamic web 
for each content element request, wherein the content 50 page. 

response includes the tagged content element if the tagged FIG. 6 depicts a preloader that is an exemplary embodi- 

content element resides in the component cache. The ment of the present invention that communicates with a 

requested content element is generated if the tagged content web/app server via an application programming interface, 
element does not reside in the component cache. A content piQ. 7 is a block diagram depicting a Preloader of an 
clement node is stored m the component cache, in response 55 exemplary embodiment of the present invention in more 

to a determination that the tagged content element does not detail 

reside in the component cache. The content element node o • ui 1 j- r 1 n_ 1 j . 

corresponds to the generated content element. Hie web page . ^ ' diagram of an exemplary Preloader that 

is deUvered with the respected content element(s). ^ configured to provide anticipatory page generation. 

In yet another aspect of the present invention, a method is 60 ^ FIG. » is a flowchart depicting a method for generatin^^ 

provided for caching a content element. A content element ^y°^^^ ^"^^ F'^e that is an exemplary embodiment of the 

retrieval request is received that corresponds to the content P^^sent invention. 

element. A retrieval response is sent, in response to the FIG. 10 is a block diagram depicting an exemplary 

content element retrieval request. The retrieval response Content Element Node. 

indicates whether the content element resides in a compo- 65 FIG. 11 is a block diagram depicting an exemplary 

nent cache. A content element insertion request is received Component Cache containing a set of Content Element 

that corresponds to the content element. An insertion Nodes. 
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FIG. 12 is a block diagram depicting an exemplary hint. 

FIG. 13 depicts a graph of the performance of a simulated 
catalog-based web site that dynamically generates catalog 
pages using an exemplary embodiment of the present inven- 
tion, s 

DETAILED DESCRIPITON 

An exemplary embodiment of the present invention 
improves web page delivery speed and web site scalability 
by prefetching and caching dynamic web page content. In lo 
one embodiment, the present invention can be implemented 
in cooperation with a profile server, such as the eOlue server, 
manufactured and marketed by Chutney Technologies, Inc. 
of Atlanta, Ga. The profile server is based on Real-time 
Interaction Management (RIM) architecture that is designed 15 
to enable organizations to build and deploy electronic com- 
merce (e-commerce) solutions that provide the user with a 
personalized shopping experience by tracking historical 
consumer behavior and reacting accordingly. Hie RIM 
architecture enables real-time querying of vast amounts of 20 
historical data to allow e-commerce businesses to anticipate 
customer needs and to provide content that is tailored for the 
customer thereby enhancing the customer's online experi- 
ence. A more detailed description of the profile server is 
provided in a co-pending application, Ser. No, 09/588,257, 25 
assigned to Chutney Technologies, Inc. A more detailed 
description of the real-time querying enabled by the RIM 
architecture is provided in a co-pending application, Ser. No. 
09/428,838, also assigned to Chutney Technologies, Inc. 
Both of these patent applications are hereby incorporated by 30 
reference. 

The Scalability Problem 

Web page delivery performance is a critical success factor 
for c -commerce. The performance of a web site is deter- 
mined by its ability to scale. Not only must a site be able to 35 
provide fast response times (i.e., web page delivery speed), 
but also it must be able to do so even under heavy user loads 
(i.e., high user trafiSc). Scalability refers to the ability of a 
web site to deliver web pages in a timely manner in high 
trafiSc situations and the ability of the web site to respond 40 
appropriately when traffic significantly increases. Thus, scal- 
ability is a critical problem for e-commerce sites. An exem- 
plary embodiment of the present invention defines a novel 
and unique dynamic web page component caching model 
that improves the scalability of web and application servers. 45 

FIG. 1 depicts the conventional steps required to satisfy a 
user's request for a web page over the Internet. As FIG. 1 
shows, the exemplary web page download is a four-step 
process, A web page typically consists of text and several 
embedded objects, often graphics. A web page can be 50 
thought of as a set of components (or content elements), 
where a component is a group of data that is displayed 
together. A user typically uses a local computer 100 to 
connect to a web server and/or an appHcation server web/ 
app server 102 via the Internet 120. Web and application 55 
servers are typically different entities, but they are collec- 
tively referred to as web/app servers here for the sake of 
simplicity. The web/app server 102 is connected to content 
databases 104, 106 either directly or via the Internet 120 (or 
some other network). The content databases 104, 106 con- 60 
tain content elements that can be accessed by the user 100 
by making a content request in the form of a web page 
request to the web/app server 102, 

When a user 100 first requests a web page via an Internet 
browser, the user's browser enters the URL for the location 65 
of the script that will generate the requested page (Step 108). 
The web/app server 102 then executes the script, which 



,168 Bl 

6 

generates the content (e.g., HTML) corresponding to the 
requested page, along with the URLs for the embedded 
objects in the page. This step involves additional work on the 
part of the web/app server 102 in order to retrieve and format 
the requested content. For example, content is typically 
retrieved from underiying database systems, such as content 
databases 104, 106 which may be located remotely. Once the 
content is retrieved, additional steps may be required to 
format the content (e.g., content stored as XML must be 
rendered as HTML). In short, the web/app server 102, upon 
receipt of the user's request, performs significant work and 
outputs the HTML (with embedded objects) thai is sent back 
to the user (Step 110). 

After the user 100 receives the server output (Step 110), 
subsequent requests are made by the user's browser for the 
embedded objects (Step 112) (browsers differ in the number 
of objects they can retrieve per request). These objects are 
often located on the web/app server 102 (though this is not 
always the case). The web/app server 102 returns the objects 
to the user over the Internet (Step 114). This last step can be 
quite bandwidth intensive. Pages having a large number of 
embedded objects can have significantly longer download 
times. Moreover, the traffic between the client and server 
must go through an extensive network of transmission and 
switching devices such as routers, switches, and firewalls. 
Thus, the communication between the user 100, the web/app 
server 102, and any involved content databases 104, 106 can 
be extremely consumptive of time and computing resources. 

Given the above-identified steps involved in downloading 
a web page, a number of potential bottlenecks can be 
identified. These bottlenecks can be classified into four 
broad areas: 

1. low bandwidth at the user and/or web/app server ends, 

2. page generation latency, 

3. fetching embedded objects, and 

4. redimdant connections to serve the same objects. 
Each of these types of delay is next described in more 

detail. 

Delays due to low bandwidth concern network speeds. 
Since the Internet backbone is high-speed, bandwidth prob- 
lems OCCULT primarily at the user and/or web server ends. In 
the past, modem speeds have limited the ability to achieve 
fast Internet access speeds and thus have contributed to slow 
download times. More recently, however, the advent of 
higher bandwidth access technology, such as broadband 
modems, has significantly improved this problem. For this 
reason, the bandwidth problem is becoming less of an issue. 

Delays associated with page generation latency are caiised 
by the work that is required by the web/app server 102 to 
deliver the requested content. This type of delay occurs 
between Steps 108 and 110 in FIG. 1. The page generation 
latency component was not considered to be a significant 
problem until very recently, because the additional response 
of the web server 102 was to transmit a static HTML page 
to the user 100. With the increasingly widespread use of 
dynamic page generation technologies, this problem has 
become a critical issue, because so much more work is 
required of the web/app server. Page generation latency 
delays include the delays due to retrieving content from 
persistent file systems such as content database systems 104, 
106 (both local and remote), the delays due to the web/app 
server's 102 formatting the content elements, and the delays 
due to business logic execution (e.g., personalization logic). 

Fetching embedded objects (Step 112) incurs additional 
network delay. Typically, a user 100 and a web/app server 
102 are separated by long distances, and embedded objects 
that are requested must be downloaded over these long 
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distances. This caiises a delay, because these large pieces of alone cannot be presented in a meaningful way, there is a 
data move relatively slowly, given the switching that is need to separate the content and presentation aspects of a 
required to make a connection over a significant distance. web page. This separation is made possible by the use of 
Solutions to this problem are available and generally involve XSLT (Extensible Stylesheet Language Transformations), a 
an attempt to ameliorate these delays by locating data (e.g., S language tised to transform an XML document into some 
embedded objects) closer to end users (i.e., storing rich o^^** specified format (e.g., HTML text). A number of 
content objects on servers that are located close to end vendors offer XSLT processors which perform such trans- 
users). Thus, this approach reduces the travel distance formations. This XML to HTML transformaUon process 
required for content delivery and decreases the number of "^f ceases the load on the server, smce it involves parsing and 
hops from content provider to end user. other strmg-prDoessing operations. 

The problem of redundant connections concerns page Yet another kmdof page generation delay is ca^^^ 

^ ^ 11 I- L . . • 11 . need to execute busmess logic. It is common for web sites 

request generauy tacn page request typicaUy must go ^ incorporate business loeic into their scripts. For example, 

through a router, firewall, and switch before reaching the e-commerce sites ulilize personalization software to 

web server 102, where l is processed and then passed back deliver targeted content to site visitors, which further 

through the same network components. Forcing each request is increases the load on web/app servers as well as on the 

through these devices, each having finite throughput, can underlying databases. 

easily expose scalability problems. Furthermore, as more Web page generation latency is a substantial problem and 

and more users try to access the same content, the redundant in many cases is the primary impediment to efficient web 

load on the firewalls and servers for the same objects page generation and delivery. FIG. 2 depicts a graph of the 

increases dramatically. While sites are increasingly using 20 performance of a conventional catalog-based web site that 

dynamic page generation technologies to generate content dynamically generates catalog pages. The performance 

on demand, there are still a large number of objects on a curve 200 plots the average page generation time for a given 

given web page that are static. In fact, it is estimated that as number of users accessing the web site. For this web site, the 

much as 90% of web objects can be static. Solutions to this only relevant component of page generation latency is the 

problem are available and generally involve attempting to 25 I/O delay, as there are no remote resources involved and no 

reduce the number of redundant connections for such objects transformations are taking place. Thus the performance 

by caching these objects and thereby reducing the load on curve 200 depicted provides the lower boimds for page 

the origin servers. However, this problem will become less generation latency delay. The web site used to obtain the 

of an issue over time as embedded objects are increasingly results depicted in FIG. 2 is a relatively simplistic web site 

becoming dynamic (e.g., Java applets). 30 in that it does no additional processing beyond displaying 

The four broad areas described above have received catalog pages. Many e-commerce sites are also incorporat- 

varying degrees of attention. As mentioned previously, the ing technologies to deliver targeted content (such as per- 

bandwidth problem has received significant attention and is sonalization software), which further increases the load on 

therefore not expected to be an issue in the future. The latter web/app servers as well as the underlying content databases, 

two problems, fetching embedded objects and redundant 35 For sites utilizing both dynamic scripts as well as content 

connections, have also received significant attention targeting technologies, scalability issues are even more of a 

recently, and a number of viable solutions exist on the concern. 

market. Furthermore, these two problems concern latency on As depicted by the performance curve 200 in FIG. 2, for 

the network. In the long term, it is unclear whether network relatively small user loads (less than 1000 simultaneous 

latency will remain an issue given the impending arrival of 40 users), the average time required to generate a page is 

terabit (TB) network bandwidths. The problem of page reasonable: roughly around 500 milliseconds. However, 

generation latency is one that has not yet been adequately when the load increases beyond 1000 users (stdl a moderate 

addressed. The present invention provides a novel solution load by today's e-commerce standards), there is a dramatic 

to this problem. spike in the page generation time. This spike is due to the 

The Page Generation Latency Problem 45 inability of the underlying database system to keep up with 

The problem of page generation latency concerns the the incoming requests, 
delays associated with generating pages at the web/app There are currently no solutions available on the market 
server 102. This problem, while significant, has been largely that explicitly address these dynamic page generation pro- 
overlooked. In addition to pure script execution overhead, cessing delays. While some caching may be done by a 
which itself can be non-trivial under moderate to heavy so database management system (DBMS) (e^ecially with the 
traffic load, there are several other types of delay associated advent of main memory database systems) or the web/app 
with generating dynamic pages. These types of delay are server, this caching does not mitigate the problem of access- 
next described in more detail. ing remote databases, nor does it address the problem of data 

One kind of page generation delay is caused by fetching transformations. The existing scaling solutions do not 

content from persistent storage. This kind of delay is attrib- 55 impact server latency at all. Moreover, given that I/O times 

u table tot he need to retrieve data stored on a disk, a have reduced by a factor of only 2,5 times during the last 

notoriously slow operation. This delay can be further clas- decade (as opposed to network latencies, which have 

sified according to the two types of access required: a) local reduced by a factor of lOg), the problem of 1/0 delay is a 

database access, and b) remote database access. Both types legitimate concern. The problem itself is new, and is a result 

of access to database systems incur input/output (I/O) delay. 60 of the introduction and rapid deployment of dynamic page 

Access to remote database systems is even more costly as it generation technologies. In many cases, page generation 

incurs network delay in addition to I/O delay. bottlenecks become the dominant impediment to efficient 

Another kind of page generation delay is caused by the dynamic web page generation, and thus to the overall 

need to perform data transformations. Given the overwhelm- scalability of the site. While the conventional approach is to 

ing acceptance of XML as a medium of exchange and as a 65 buy more hardware and software, this is clearly not an 

means of describing content, Web sites are increasingly attractive alternative in terms of cost, and is often an 

maintaining content in XML formal. However, since XML infeasible solution in the long nm. 
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To solve this problem, an exemplary embodiment of the 
present invention provides a server-side caching engine that 
caches dynamic web page elements (content elements or 
components), thereby significantly reducing the page gen- 
eration load on the web/app server. One embodiment of the 5 
present invention provides a Preloader that is a server-side 
caching model for caching page elements in cooperation 
with commonly used dynamic page generation technologies. 
The Preloader model can be implemented as a 'software 
solution or as a stand-alone appliance. An exemplary lo 
embodiment of the present invention capitalizes on the 
above-referenced profile server technology to improve web 
page delivery speed and web site scalability by prefetching 
and caching web page components. A brief description of the 
operation of an exemplary profile server is, therefore, ben- 15 
eficial to providing a complete description of the present 
invention. 

An Exemplary Profile Server 

FIG. 3 is a block diagram depicting an exemplary profile 
server 300 in the context of an exemplary e-commerce web 20 
site's web/app server 302 that generates dynamic web pages 
to a user 304, 306. The profile server 300 has a session log 
308, a Profiler 310, a Rule Warehouse 312, and a Data 
Mining Engine 314. 

An exemplary Profiler 310 consists of three components: 25 
(1) a Clickstream Cache 316, which stores current click- 
stream information (of maximum clickstream length CSL) 
for each user 304, 306 in the system, (2) a Profile Cache 318, 
which stores recently-used profiles, and (3) a Profile Man- 
ager 320, which generates hints for the web/app server 302, 30 
in response to a hint request from the web/app server. A 
clickstream is simply a series of recorded user actions (e.g., 
clicks on web page hyperlinks) in the sequence in which the 
user took the actions. 

To illustrate the mechanics of the hint generation process, 35 
it is helpfiil to consider the example of a user visiting a web 
site that employs the profile server 300. Consider a situation 
where the web/app server 302 has submitted a hint request 
to the profile server 300 for the user'si"''' click. The Profile 
Manager 320 first checks the Clickstream Cache 316 to find 40 
the. user's previous clickstream (if any), and any updates 
that include the user's latest reported action. 

After determining the user's current clickstream, the 
Profile Manager 320 checks the Profile Cache 318 for a 
profile matching the user's clickstream. If such a profile is 45 
found, the Profile Manager 320 generates a hint from it, and 
sends the hint to the web/app server 302, If, at this point, 
another user were to follow the same path as the first user, 
then the needed profile would be in the Profile Cache 318 
(assuming the second user visits the web site soon enough 50 
after the first user that the profile has not been replaced by 
a newer profile). 

If a matching profile is not found in the Profile Cache 318, 
the Profile Manager 320 requests the information from the 
Rule Warehouse 312. The operation of the Rule Warehouse 55 
312 is described in more detail below After the Rule 
Warehouse 312 returns the profile information, the Profile 
Manager 320 generates a hint, and sends it to the web/app 
server 302. This profile will also now reside in the Profile 
Cache 318 until a decision is made to discard it. 60 

The Rule Warehouse 312 is a data warehouse engine that 
is an extremely fast storage and retrieval engine. The Rule 
Warehotise 312 is described in more detail in a co-pending 
patent application, Ser. No. 09/428,838, also assigned to 
Chutney Technologies, Inc. This patent application is hereby 65 
incorporated by reference. In the context of the profile server 
300, the Rule Warehouse 312 stores historical and naviga- 
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tional data in the form of rules, and retrieves this data in 
response to queries. 

The rules stored in Rule Warehouse 312 are generated by 
a conventional data mining engine which takes a clickstream 
(e.g., stored in the Session Log 308) and transaction infor- 
mation generated by various users clicking in the web site, 
as input, and generates a set of rules as output. Clickstream 
and transaction data is added to the Session Log 308 in an 
online fashion (i.e., for each user request), while the mining 
of the Session Log 308 and update of the Rule Warehouse 
312 takes place offline (i.e., periodically, such as daily). 

The rules used in profile server 300 are action rules and 
take the form: 



Actioni-Nodftj, Actionj-Nodcj, . . . Action^ c/ -Node ^y f -»Ac- 
tioa^-NodCj,; probability (p) 

wherein ActioUy-Nodey can be a navigation click, a purchase 
click, or a departure click associated with Node j. Those 
skilled in the art will appreciate that any other action could 
also be accommodated. The antecedents of the rules are of 
a predetermined and configurable maximum length CSL, 
and correspond to a certain minimum confidence threshold 
and a minimum support threshold. The hints that are 
returoed by the Profiler are in the form of a dynamic profile. 

A dynamic profile, is a 2-tuple (RA, RC) of information 
where RA is a mle antecedent (Le., a user clickstream of 
length CSL) and RC is a set {ci,C2, . . . , c„} of rule 
consequents c^, where each c,, is itself a 3-tuple (A,L,p) 
where: A is an action; L is a node label; and p is the 
conditional probability of the consequent, given the ante- 
cedent. 

Rules in the Rule Warehouse 312 are periodically updated 
to incorporate recent behavior. Note that generating and 
maintaining rules is an offline process and is an important 
feature of the profile server 300. However, this feature is not 
native to the profile server 300 itself, but rather is handled 
by a conventional data mining engine, which is incorporated 
as part of the overaU solution. 

The best way to describe the overall workings of the 
profile server system is to consider an example. Consider a 
user who clicks in a profile server 300 enabled e-commerce 
web site. This causes a Hypertext Transfer Protocol (HTTP) 
request to be sent to the web server. Those skilled in the art 
will appreciate that although the e-commerce and web 
servers are conventionally separate components, they can 
also be implemented as a single component. When the web 
server 302 receives an HTTP request from the user, it 
forwards the user's click information to the profile server 
302 in the form of a Hint Request. 

Upon receiving the user's click information, the profile 
server 302 performs two tasks. First, the profile server 302 
updates the user's clickstream. Second, the profile server 
302 generates a hint. A hint is simply a set of action-node - 
probability tuples, which represent actions that the user is 
likely to take on a particular node, together with the corre- 
sponding probability that the user will choose the action- 
node, given his current clickstream. 

When the web/app server receives a hint from the profile 
server 302, it tises the hint to generate a customized web 
page for the tiser. Typically, the web server 302 runs a set of 
scripts that describe how a dynamic web page should be 
generated in different situations. In a profile server system, 
these scripts include business logic to handle profile server 
hints. Profile server hints may also be used to pre-generate 
and cache pages or components of pages. The pre-geoeration 
and caching of web pages and/or web page content elements 
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is performed in conjunction with a Preloader module, which 
we will describe in more detail in connection with FIGS. 
4-U. 

The use of these hints is best described by considering an 
example in the context of the Preloader. Consider a situation S 
where a user has navigated through a particular sequence of 
product catalog nodes. Further assume that, on the user's i*'' 
click, the profile server 300 returns a hint to the web/app 
server 302, suggesting that the user is highly likely to 
navigate to a particular node N on the user's next click (i.e., lo 
action/consequent), given his current clickstream (i.e., 
antecedent). Based on this information, the web server can 
proactively cache the content of node N, so that N is 
available in cache when the user clicks. If the user, in fact, 
requests access to node N, then the content of node N will 15 
be more quickly available to the user, because it has been 
cached and need not be retrieved. 

In addition to the real-time server-side interaction with the 
profile server 300, each user click causes a Qiclcstream 
Monitor to send user session (i.e., click) information to the 20 
profile server 300, where it is stored in the Session Log 308 
for later use in updating the Rule Warehouse, The Chck- 
stream Monitor module can be a client-side Java applet that 
sends chcks (including client-side cache hits) to a server or 
a server-side logging mechanism. In this arrangement, 25 
client-side logging provides a more complete record of user 
behavior than server-side logging, but requires that the 
user's browser be Java-enabled. Since the information 
stored in the Session Log 308 is used for refreshing the Rule 
Warehouse (an offline operation), there is no requirement for 30 
this interaction lo occur in real time. 

The profile server 300 works in conjunction with conven- 
tional web servers 302 and e -commerce application servers 
to provide the functionalities we have described. The profile 
server 300 provides hints to the Page Generator 322, which 35 
then generates a page for each user cUck. The Page Gen- 
erator 322 then synthesizes web pages by integrating content 
from various sources and formatting the content as neces- 
sary (e.g., into HTML pages). Web page content is drawn 
from various sources, including the Product Catalog 324 40 
having a product hierarchy 326 (which stores product infor- 
mation in hierarchical format as well as detailed information 
about each product) and catalog data module 330. Web page 
content can also be drawn from a store of static content 328 
(i.e., content not associated with a particular product catalog 45 
node, such as a corporate logo), and a server cache (not 
shown). Communication between the profile server and web 
server follows a client-server paradigm, wherein the web 
server requests hints from the profile server 302, and the 
profile server 302 provides hints in response. 50 

FIG. 4 depicts a Preloader 400 that is an exemplary 
embodiment of the present invention. The Preloader 400 
works in conjunction with the profile server 300 to manage 
the profile server Preloader Component Cache. The Pre- 
loader 400 obtains predictive information from profile server ss 
300 which is used to determine which content elements to 
maintain in the Preloader Component Cache and which to 
discard. Consider the example of a user who visits a favorite 
online bookseller. Assume that the user enters the site at the 
web site's home page, then navigates the following path: 60 
Fictions -►Thriller-^Legal-^Thriller, The Preloader-enabled 
web .site can maintain detailed behavioral data about visi- 
tors to the site, so the web site is able to recognize that users 
who navigate the Fiction— *Thriller->Legal Thriller path 
most often visit the John Grisham link next. With the 65 
Preloader application installed, the web site can cache 
content elements associated with the John Grisham link so 



that it is inunediately available when a user requests it. This 
type of content element caching can have far-reaching 
effects in terms of scalability of the site, given that there may 
be tens of thousands of simultaneous users at the site. The 
following discussion provides a detailed description of the 
structure and operation of the Preloader in conjunction with 
a profile server and a web/app server. 
An Exemplary Preloader Architecture 

To explain the Preloader architecture and concept first 
requires an understanding of how dynamic scripting works. 
Examples of dynamic scripting languages include Java 
Servlets, Java Server Pages (JSP), Active Server Pages 
(ASP), Perl, and CGL A dynamic script typically consists of 
a number of code blocks, where each code block performs 
some work that is required to generate the page (e.g., 
retrieving or formatting content) Typically, a dynamic script 
produces an HTML firagment as output. While a fragment 
can be in any formal,it is assumed for this discussion that the 
format is HTML. A WRITE TO OUT statement, which can 
follow each code block, can be used to place the resulting 
HTML fragment in a buffer. When a dynamic script runs, 
each code block is executed and the resulting HTML frag- 
ment placed in the buffer. Once all code blocks have 
executed, the entire HTML page is sent as a stream to the 
user. FIG. 5 depicts a high-level block diagram of an 
exemplary dynamic scripting process. The buffer is not 
shown in FIG. 5 for the sake of simplicity. The resulting 
dynamic web page that is generated by the scripting process 
thus consists of a set of fragments or components. For the 
purposes of describing an exemplary embodiment of the 
present invention, the terms content element, content, 
component, and fragment are aU used to refer to a collection 
of data that is displayed together on a web page. 

A dynamic web page can be thought of as a set of such 
content elements. For example, consider a dynamically 
generated web page 500 in a news site, as shown in FIG. 5. 
At the top of the web page is an Ad Component 502, where 
a banner ad is displayed. On the left side of the web page is 
a Navigation Component 504, which contains a navigation 
bar. In the center of the web page 500 is a Current Headlines 
Component 506, which contains links and descriptions of 
the cunrent top stories. Finally, at the bottom of the page is 
a Personalized Component 508, which contains items that 
are of particular interest to an individual user (e.g., news 
items related to user-specified preferences), based on some 
predetermined indication of the user's preferences. 

A significant advantage provided by this dynamic web 
page is the potential for re-use of the content For example, 
for each user that requests this page, the Current Headlines 
506 and Navigation Components 504 that are displayed will 
likely be identical. Thus, these components arc especially 
conducive to caching. At the other extreme, the Personalized 
Component 508 may be unique for each request, and is thus 
less conducive to caching. In some situations, a component 
is not cacheable. For example, a component that displays the 
current time is not cacheable. Thus, from the perspective of 
the Component Cache 402 (FIG. 4), there are two types of 
content elements: cacheable and non-cacheable content ele- 
ments. Non-cacheable content elements are those that may 
change between each web page generation, and hence 
should not be cached. All other content elements are con- 
sidered to be cacheable. 

As indicated by the dashed lines 510, 512 in FIG. 5, each 
code block 514, 516 corresponds to a component of the 
dynamic web page 500. The Preloader solution requires that 
cacheable components be identified. This decision is made 
by the web site designer. For each component that is deemed 
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cacheable, the corresponding code block 514, 516 in the 
script 550 must be tagged or marked as cacheable. A tag is 
an identifier that marks a code block within a script as 
cacheable. When the script 550 is executed, the tags instruct 
the web/app server to first check the Component Cache 402 S 
(FIG. 4) before executing the code block. If the requested 
fragment is found in the Component Cache 402, then it is 
returned directly firom the cache and the code block logic is 
bypassed. If the requested fragment is not found in the 
Component Cache 402, then the code block is executed and lo 
the requested fragment is generated and subsequently placed 
in the cache. 

FIG. 6 depicts a simplified, high-level block diagram of 
an exemplary Preloader architecture. The Preloader 600 is 
considered a middle tier caching solution since it resides 15 
adjacent to the web/app server 602. The web/app server 602 
communicates with the Preloader 600 through a cHent 
application programming interface (API) 603. The main 
components of the Preloader 600 arc the Cache Manager 
604, Cache Replacement Manager 606, and the Component 20 
Cache 608. The Cache Manager 604 handles aU requests 
from the client (i.e., web/app server 602). 

There are three types of requests: 1) component retrieval 
requests, 2) component insertion requests, and 3) component 
removal requests. The first two types of requests are made by 25 
the web/app server 602, while the last type is made by the 
Cache Replacement Manager 606. A component retrieval 
request invokes a cache lookup to determine whether the 
requested component exists in cache. The Cache Manager 
604 responds to a component retrieval request with an 30 
indication as to whether the component was found in cache 
and, if found, returns the component. A component insertion 
request invokes an insertion of a component into the cache. 
This type of request is made by the web/app server after a 
cache miss occurs. The Cache Manager responds to a 35 
component insertion request with an indication as to whether 
the component was successfully inserted into the cache. 

The Cache Replacement Manager 606 makes replacement 
decisions in the cache when the cache becomes full. When 
it is determined that a cache item should be removed, a 40 
component removal request is sent to the Cache Manager 
604. The dashed line 610 in FIG. 6 between the web/app 
server 602 and the Cache Replacement Manager 606 indi- 
cates the behavior updates that are optionally passed to the 
Cache Replacement Manager 606. This communication 45 
occurs when a predictive cache replacement policy 
(described in more detail below) is used. The Cache 
Replacement Manager 606 can utilize any type of cache 
replacement policy (e.g., LRU), and the best policy to use 
may be dependent upon the application. 50 

An exemplary embodiment of the present invention uti- 
hzes a predictive cache replacement policy that is designed 
for caching web page components. This predictive cache 
replacement policy is referred to as the Least-Likely-to-be- 
Used (LLU) policy. When choosing a replacement "victim" 55 
in the cache, it takes into account not only how recently a 
cached item has been referenced, but also whether any user 
is likely to need the item in the near future. LLU is described 
in more detail below. For the purposes of this description, 
the Preloader architecture is described in connection with 60 
the use of LLU replacement. 

Referring again to FIG. 4, the LLU Preloader architecture 
is depicted as a block diagram. The LLU Preloader com- 
municates with a profile server 300 in order to obtain 
predictive information to tise in making cadae replacement 65 
decisions. More specifically, the Cache Replacement Man- 
ager 404, upon receiving a behavior update from the web/ 
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app server 302, sends a hint request to the profile server 300. 
Based on the hint response received (and possibly other 
information, such as last access time), the Cache Replace- 
ment Manager 404 determines which items to remove and 
sends the corresponding requests to the Cache Manager 406. 

FIG. 7 depicts a block diagram depicting an exemplary 
LLU Preloader 700 in more detail. The web/app server (not 
shown) sends a component request to the Cache Manager 
714, which is serviced as described above. The Preloader 
Cache Replacement Manager 706 controls the cache 
replacement policy. The Cache Replacement Manager 706, 
upon receiving a behavior update from the web/app server, 
places a hint request in the Request Queue 708, The Query 
Dispatcher 710 services requests in the Request Queue 708 
in a first-in-first-out (FIFO) order, and thus sends the appro- 
priate request to the Profiler 450 (FIG. 4). The Profiler 450 
retrieves the corresponding hints and sends them to the 
Response Manager 712. The Response Manager 712 places 
the hints in the Response Queue 716. The Preloader Cache 
Replacement Manager 706 services hint responses from the 
Response Queue 716 in FIFO order. The Preloader Cache 
Replacement Manager 706 utilizes the hints (and possibly 
other information, such as last access time) to determine 
which components in the Component Cache 718 to remove. 
The appropriate removal requests are then sent to the Cache 
Manager 714. 

The Preloader architecture supporting on-demand page 
generation is shown in FIG. 4, as described above. In this 
embodiment, the web/app server sends component requests 
to the Preloader Cache Manager 406. If the requested 
component is in the Component Cache 402, it is returned to 
the web/app server Otherwise, the web/app server executes 
the script logic necessary to generate the requested compo- 
nent and then writes the component to the Component Cache 
402. Based on the component requests received from the 
web/app server, the Cache Replacement Manager sends hint 
requests to the Profiler 450 (FIG. 4). The hint responses that 
are returned from the Profiler 450 are used to make replace- 
ment decisions in the cache. 

In an exemplary embodiment of the present invention, the 
Component Cache 402 contains content elements, rather 
than whole web pages. Essentially, a web page consists of a 
set of content elements, which are defined by the apphcation 
(these terms wiU be formally defined in the next section). By 
caching at the content element level, the Preloader 400, is 
able to reuse content elements that are commonly requested, 
even though other elements on the page may change. For 
example, the Current Headlines Component in the news site 
example would be common to all requests for a particular 
page, whereas the Personalized Component would likely be 
different for each request and thus should not be cached. 

In an alternative embodiment of the present invention, the 
Preloader architecture supports both on-demand and antici- 
patory page generation, FIG. 8 is a block diagram of an 
exemplary Preloader 800 that is configured to provide 
anticipatory page generation. The primary difference 
between this embodiment and the embodiment described in 
connection with FIG. 4 is that two web/app servers 802, 804 
(i.e., more than one web/app server) are used for anticipatory 
page generation. One web/app server 802 is used to generate 
pages for the usual on-demand requests described in con- 
nection with FIG. 4. A secondary web/app server 804 is used 
to generate pages for anticipated requests. Thus, as 
described in connection with FIG. 4, the on-demand portion 
remains the same. The secondary web/app server 804 is used 
to generate content in anticipation of ^ture requests. 

The Preloader Cache Replacement Manager 810 performs 
as described above, by requesting hints from the Profiler 850 



04/09/2004, EAST Version: 1.4.1 



us 6,622 

15 

and using these hints to make replacement decisions in the 
Component Cache 806. The only additional work required 
by the Preloader Cache Replacement Manager 810 is that it 
sends hints to the secondary web/app server 804 so that the 
secondary web/app server can generate content that may be 5 
requested in the near future. The secondary web/app server 
804 sends component insertion requests to the Preloader 
Cache Manager 814, which then updates the cache. Thus, 
the Component Cache 806 is shared by the primary and 
secondary web/app servers 802, 804, lo 
An Exemplary Method for Dynamic Web Page Generation 

FIG. 9 is a flowchart depicting a method for generating a 
dynamic web page that is an exemplary embodiment of the 
present invention. The method begins at step 900 and 
proceeds to step 902. At step 902, a page request is received. 15 
The method then proceeds to decision block 903. At decision 
block 903, a determination is made as to whether the page 
request has any remaining content elements that have not 
been supplied. If no content elements remain unsupplied, 
then the method proceeds to step 905 and ends. 20 

If, at decision block 903, a determination is made that at 
least one content element remains unsupplied, then the 
method branches to decision block 904. At decision block 
904, a determination is made as to whether the remaining 
content element is found in a component cache. If the is 
content element is not found in the component cache, then 
the method branches to step 912 and the content element is 
generated. In one embodiment of the present invention the 
generation of content elements can be handled by the 
web/app server. The method then proceeds to step 906. If, on 30 
the other hand, the content element is found in the cache, 
then the method branches from decision block 904 to step 
906. At step 906, the content element is placed in a bxififer. 

The method proceeds from step 906 to step 908 and the 
buffer elements that were not found in cache are written to 35 
the component cache. The method then proceeds to step 910 
and the web page is delivered. The method then proceeds to 
step 914 and ends. Notably, the same method can be applied 
whether providing web pages on an on-demand basis or on 
an anticipatory basis. The difference is that the page requests 40 
in the anticipatory page generation context will include 
requests for pages that have not actually been requested by 
the user, but are expected to be requested by the user. When 
utilized in the context of the Preloader of FIG. 7, the method 
for web page generation processes each content element in 45 
a web page. It first checks the Component Cache 718 to 
determine whether the component exists in the cache. 
Details of how the cache is structured and accessed will be 
discussed in more detail below, in connection with FIGS. 
8-10. In the case of a component hit (content element found 50 
in Component Cache 718), the component is simply placed 
in the b\iffer. In the case of a component miss (content 
element not found in Component Cache 718), the compo- 
nent is generated according to the conventional script logic, 
and then placed in the buffer (not shown). Content elements 55 
can be stored in any format. After aU content elements have 
been processed according lo this exemplary method, any 
additional logic required by the server is executed. Next, the 
buffer elements that were not foimd in cache are written lo 
the Component Cache 718, and the web page is returned to 60 
the requesting user. Because the Preloader Cache Manager 
and the Preloader Cache Replacement Manager play such 
important roles in both embodiments, a more detailed dis- 
cussion of each follows. 

An Exemplary Preloader Cache Manager 65 

The exemplary Cache Manager handles all requests from 
the client (i.e., web/app server). In one embodiment of the 



,168 Bl 

16 

present invention, there are three types of requests: 1) 
component retrieval requests, 2) component insertion 
requests, and 3) component removal requests. The first two 
types of requests arc made by the web/app server, while the 
last type is made by the Cache Replacement Manager. A 
component retrieval request invokes a cache lookup to 
determine whether the requested component exists in the 
Component Cache. The Cache Manager responds to a com- 
ponent retrieval request with an indication as to whether the 
component was found in cache and, if found, returns the 
component. A component insertion request invokes an inser- 
tion of a component into the cache. This type of request is 
made by the web/app server after a cache miss occurs. The 
Cache Manager responds to a component insertion request 
with an indication as to whether the component was suc- 
cessfully inserted into the cache. A component removal 
request is sent to the Cache Manager by the Cache Replace- 
ment Manager when it is determined that a cache item 
should be removed. The decision to remove a component is 
made by the Cache Replacement Manager, based upon a 
cache replacement policy. The Cache Replacement 
Manager, along with the LLU cache replacement poHcy, is 
described below. 

An Exemplary Preloader Cache Replacement Manager 

In an exemplary embodiment of the present invention, the 
Preloader Cache Replacement Manager controls the replace- 
ment policy of the Component Cache. The present invention 
uses a novel combination of the Preloader Cache Replace- 
ment Manager, the Component Cache structure, the cache 
states, and a replacement policy to generate on-demand and 
anticipatory web pages. 

The Component Cache consists of a configurable number 
of elements, called cachelines. Each cacheUne can store at 
most one instance of a Content Element Node. FIG. 10 is a 
block diagram depicting an exemplary Content Element 
Node 1000. The Content Element Node 1000 contains at 
least the following data components: 1) a NodelD 1002, 
which uniquely identifies each content element in the cache 
and maps each content element to a unique combination of 
Page or Script ID and Code Block ID; 2) a NavProb 1004, 
which is the conditional probabOity that a user will request 
the current content element, given that he has followed a 
path of length CSL up to the user's present clickstream 
position; 3) a Timestamp 1006, which indicates the lime that 
the element was last accessed; 4) a Content component 
1008, which holds the data for the content element in HTML 
format (or other formats); and 5) a NextNode 1010, which 
is an array structxire containing NodelDs for aU nodes that 
are reachable, in a single step, from the current node. 

The Component Cache is initially empty. A content ele- 
ment is added to the cache after it is requested. The Com- 
ponent Cache is not kept completely full, additional space is 
maintained so that content elements can be written to the 
Component Cache as soon as they are requested. Replace- 
ment decisions are then made based on the navigation 
probabilities and timestamps. 

Cachelines have two possible stales: empty and full. A 
cacheline is said to be in the empty state when the cachelinc 
contains no Content Element Node. All cachelines are empty 
at system startup. A cachelinc returns to this state when is 
has been selected for replacement, before a new Content 
Element Node has been stored in it. A cacheline enters, the 
full state when a content miss occurs. A component miss 
triggens the web/app server to send a component insertion 
request to write the requested content element to the Com- 
ponent Cache. This step instantiates the fields in the Content 
Element Node. Specifically, NodelD 1002 is set to the 
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combioation of PagelD and Code Block ID for the requested 
content element, Timestamp 1006 is set to the current time, 
NavProb 1004 is computed (as is described in more detail 
below), and the HTML corresponding to the content clement 
is placed in Content 1008. A cacheline remains in the full 5 
state until it is selected for replacement. 

To compute a navigation probability, the navigation prob- 
ability for a cacheline must first be defined. For two cach- 
elines CL,- and CLy, there are associated Content Element 
Nodes CENI and CENJ, respectively. The navigation prob- lO 
ability from CL,- to CLj is denoted by NP(CL,-*CL,), and 
represents the conditional probability that a user will request 
the content element contained in CLy, given that he has 
followed a path of length CSL up to this point. 

For a set of cachelines, {CLj, Cl^ . . . , CL„}, maximum 15 
navigation probability (MNP) of a cacheline, CL^, is denoted 
by MNP(CLi) and is given by: 



MNP(CLj)=inax(NP(CLi--CLi)^(CL2--CLj, . . 
CL,)] 



,NP(Cl^- 



For a given cacheline, CLy, having n predecessors, 
NP(CL,--»CLy) is computed in each of three different sce- 
narios as follows: 1) if the cacheline has no predecessors 
(i.e., n=0), then CLfl; 2) if the cacheline has a single 
predecessor (i.e., n=l), then CL,- is the navigation probability 25 
obtained from the Profiler; 3) if the cacheline has multiple 
predecessors (i.e., n>l), then CL^-=MNP (CLy). 

FIG. 11 is a block diagram depicting an exemplary 
Component Cache containing a set of Content Element 
Nodes. In the case where the Component Cache contains the 30 
Content Element Nodes shown in FIG. 11, it is assumed that 
the lookahead distance (LD) is 1 and CSL is 3. Each Content 
Element Node actually contains all the information 
described previously, but only NodelDs are depicted in FIG. 
11. If the content element corresponding to node N, was 35 
most recently requested (as indicated by the bold outline of 
the cacheline), then the navigation probabilities are shown 
on the arrows. For example, the navigation probability for 
navigating from CL^ to CL^ is 60%, and the navigation 
probability for navigating from CL^ to CL^ is 30%. 40 

FIG. 12 is a block diagram depicting an exemplary hint 
1200. Assuming that the Profiler has remmed the hint 1200 
(i.e., profile), then the profile indicates that there is a 70% 
probability that the user will request N^, given that the user 
has most recently requested <N„, N^,, N^>. Likewise, there 45 
is a 20% probability that the user will request N^ and a 10% 
probability that the user will request N^ These probabilities 
correspond with the arrows discussed in connection with 
FIG. 11. There is no cachehne for Nyin FIG. 11, because this 
content element is not currently in the Component Cache. To 50 
update the probabilities for CL^ and CL^, the MNP is 
determined for each. Thus, MNP(CLj)-max(70,60)-70 and 
MNP(CLJ=max(30,20)=30. These values are then stored in 
the NavProb field in the corresponding cachelines. Note that 
other methods besides MNP may be used to compute 55 
NavProb. For instance, one could compute NavProb as the 
probability that any visitor will request a particular content 
clement and thus take the union of all predecessor's prob- 
abilities. 

The navigation probabilities are updated with every user 60 
request or click. The MNP is computed online for a cach- 
eline by broadcasting a user's position to each cacheline that 
is within a configurable maximum lookahead distance 
(MLD) ahead of the user's current cacheline. Specifically, 
with each user click, the Preloader Cache Manager updates 65 
the NavProb for each cacheline within MLD ahead of the 
current cacheline, where MLD is a configurable parameter. 



Cachelines in the cache are replaced based on two criteria: 
navigation probability and timestamp. For both criteria, 
configurable threshokl values can be set to determine which 
cachelines to remove. For navigation probability, the mini- 
mum navigation probability threshold, NP^, is used for 
this purpose. Any cacheline having a navigation probability 
less than NP^^ is removed firom the cache. In order to avoid 
the possibility that cachelines may sit unused for a long time 
in the cache, we use a threshold value, T„^, to remove 
cachelines from the cache. Recall that eadi cacheline con- 
tains a timestamp indicating the most recent access time of 
the cacheline. The timestamp of each cacheline is compared 
to and those cachelines having timestamps greater 

than T,^ are removed. Note that various combinations of 
the navigation probability and timestamp policies may also 
be used. 

Improved Web Page Delivery Performance 

FIG. 13 depicts a graph of the performance of a simulated 
catalog-based web site that dynamically generates catalog 
pages using an exemplary embodiment of the present inven- 
tion. The test environment simulates an e-commercc site 
having a product catalog which contains approximately 600 
products. The site is servlct-based, running WebLogic 5.1 as 
the application server and using an Oracle 8.1.5 database to 
store the product catalog data. To introduce user load at the 
site, a number of simulated users are created that navigate 
the site, requesting various pages in the catalog. Each user 
request submits a set of queries to the underlying database 
to construct the requested catalog page. The page generation 
time, the time to construct a complete HTML page, is 
recorded for each request. 

The test configuration consists of two clusters of 
machines, a cluster of servers and a cluster of clients. Each 
machine is a Dell Optiplex GX 110 having 512 MB RAM 
and a Pentium III 600 Mhz processor. There are four servers 
in the server cluster, each running WebLogic on an NT 
Server 4.0 SP 5 platform and communicating with its own 
Oracle database instance. There are eight clients in the client 
cluster, each running a web server that sends requests to the 
server cluster. 1\vo sets of experiments were run, one using 
a database connection pool size of 20 and the other a 
connection pool size of 50. The database connection pool 
size is the maximum number of open connections to the 
database. Thus, in general, the higher this number, the better 
the performance. For each experiment, the number of users 
was varied to show scalability. To simulate user load, each 
user clicks at a rate of one cUck every 10 seconds. 

Results for the connection pool size of 20 are shown in 
FIG. 13. The horizontal axis shows the number of users, 
while the vertical axis shows the average page generation 
time in milliseconds. In the case where no caching is 
employed, the uppermost curve 1300, the page generation 
time increases dramatically once the load increases beyond 
1000 users. This spike is due to the inability of the under- 
lying database system to keep up with the incoming 
requests. 

Where an exemplary Preloader has been used, the low- 
ennost curve 1302, exhibits a very flat shape due to its 
ability to retrieve much of the requested content from cache. 
Thus, the load on the underlying database is substantially 
reduced in this case. In terms of the magnitude of the 
performance differential, the Preloader is more than 6 times 
faster than the non-cache case for smaller loads (200 users), 
more than 20 times faster for moderate loads (3500 users), 
and more than 46 times faster for larger loads (7500 tisers). 

Although the present invention has been described in 
connection with various exemplary embodiments, those of 



04/09/2004, EAST Version: 1.4.1 



us 6,622,168 Bl 



19 



20 



ordinary skill in the art will understand that many modifi- 
cations can be made thereto within the scope of the claims 
that follow. Accordingly, it is not intended that the scope of 
the invention in any way be limited by the above description, 
but instead be determined entirely by reference to the claims 5 
that follow. 

What is claimed is: 

1. Aweb page delivery system for dynamically generating 
a web page having at least one content element, the delivery 
system comprising: lo 

a web/app server operative to receive a web page request 
from a xiser to generate a web page and to deUver the 
web page to the user, said web/app server further 
operable to generate a hint request; 

a preloader operative to receive a content element 
retrieval request from the web/app server and to deliver 
the at least one content element to the web/app server, 
wherein the preloader is in communication with the 
web/app server, and wherein the preloader comprises a 
component cache, local to the web/app server, for ^ 
maintaining the at least one content element; and 

a profile server operative to receive the hint request from 
the preloader and to deliver a hint to the preloader; 

wherein the preloader delivers the at least one content 25 
element to the web/app server in response to a deter- 
mination that the hint indicates that the at least one 
content element will be needed by the web/app server 
to generate the web page, and wherein the at least one 
content element is provided by the component cache 30 
local to the web/app server to reduce the time required 
to generate the web page. 

2. The web page delivery system of claim 1, wherein the 
preloader is further operative to receive a content element 
insertion request from the web/app server and to service the 35 
request, in response to receiving the content element inser- 
tion request. 

3. The web page delivery system of claim 1, wherein the 
preloader further comprises a cache manager operative to 
receive the content element retrieval request and the content 40 
element insertion request and to determine whether the at 
least one content element resides in the component cache. 

4. The web page delivery system of claim 3 further 
comprising a secondary web/app server that is operative to 
send component insertion requests to the cache manager. 45 

5. The web page delivery system of claim 1, wherein the 
preloader further comprises a cache replacement manager 
operative to control a replacement policy of the component 
cache. 



6. A method for delivering a web page, the method 
comprising the steps of: 

receiving a web page request, the web page request 
corresponding to a web page having at least one 
requested content element; 

determining whether a tagged content element resides in 
a component cache, the tagged content element corre- 
sponding to the at least one requested content element; 

generating a content response for each web page request, 
wherein the content response includes the tagged con- 
tent element if the tagged content element resides in the 
component cache; 

generating the requested content element if the tagged 
content element does nto reside in the component 
cache; 

generating a hint request; 

storing a content element node in the component cache, in 
response to a determination that the tagged content 
element does not reside in the component cache, the 
content element node corresponding to the generated 
content element; 

delivering at least one other content element in response 
to the determination that the hint request that the at least 
one other content element is needed to generate the web 
page; and 

delivering the web page comprising the at least one 
requested content element and the at least one other 
content element. 

7. The method of claim 6, further comprising the step of 
generating a hint request associated with the content element 
node, the hint request comprising the likelihood that the 
requested content element will be needed by a future web 
page request. 

8. The method of claim 7, further comprising the steps of 
receiving a hint response associated with the hint request, in 
response to the generation of the hint request; and 

making a cache replacement decision, in response to 
receiving the hint response. 

9. The method of claim 8, wherein the cache replacement 
decision indicates whether the requested content element 
should be maintained in the component cache. 

10. The method of claim 6, wherein the content response 
comprises an indication as to whether the tagged content 
element resides in the component cache. 
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